---
title: "Redis 做分布式 Session 管理"
created: 2025-11-25
---
# Redis 做分布式 Session 管理

面试官您好，关于 Redis 分布式 Session 管理的部分，我是这样实现的：

为了方便项目的拓展，我们平台的用户登录状态不能只保存在某个单一服务器的内存里，因为后端可能需要部署在多个实例上的，用户的请求需要打到不同节点上。所以如果用原生的
HttpSession 是做不到共享的。为了解决这个问题，我将 Session 统一托管到 Redis 中，实现了跨服务共享登录状态。

### 实现方式上，我做了以下几点：

1. **Token机制代替传统 SessionId**：

   登录成功后，生成一个自定义的登录 Token（用 UUID + 用户ID + 时间戳混合生成），作为 Redis 的 key；

   然后将用户登录态信息（如 userId、角色、权限列表、基本信息）存入 Redis 中，设置一个合理的 TTL。
2. **客户端携带 Token**：

   登录后的 Token 通过响应头或放在 Cookie 里返回给客户端；

   后续请求中客户端携带这个 Token，后端拦截器会解析并从 Redis 读取用户状态进行鉴权。
3. **Redis 键结构设计**：

   我采用的 key 结构是：`login:session:{token}`，value 是一个序列化的 UserVO ，设置过期时间（比如
   30 分钟），每次访问会重置过期时间实现自动续期。
4. **与权限控制联动**：

   这个 Redis 中的用户信息是后续权限校验的核心数据来源，比如 RBAC 模型中角色和权限列表，也一并存在这个结构里，避免每次查数据库。

---

### 为什么使用 Redis，而不是 JWT 单点机制？

这是我权衡后的选择。虽然 JWT 无状态、前后端分离的优点确实明显，但它不能主动失效，比如用户退出登录、换设备登录时，旧 Token 无法立刻失效。而
Redis 是有状态的，可以支持**主动登出、强制下线、动态踢人**等需求，更适合我的业务场景，比如我平台就支持“最多同时登录三台设备，多了会踢掉最早设备”的机制。

---

### 扩展点：多设备限制怎么做的？

我在 Redis 中额外维护了一个 `login:user:{userId}` 的列表或有序集合，记录当前用户登录的设备Token和时间。新设备登录时，判断是否超过三台，如果超过就找到最早的一台
token，删掉对应的 `login:session:{token}` 键，从而实现主动踢人。

---

### 可预见的问题和应对措施：

- **Redis宕机/数据丢失**：为了容灾，我配置了 Redis 高可用模式，使用 RDB + AOF 持久化；
- **Token伪造风险**：所有 Token 都做了随机加密，且 Redis 中保存了 UserAgent 和 IP
  信息，作为风控参考；
- **并发访问过期问题**：加了定时刷新策略，只要在有效期内访问，Redis 的 TTL 会自动续期，避免用户被误踢。

---

所以整体来说，使用 Redis 管理 Session 是一种兼顾**安全性、灵活性和分布式扩展性**的方案，尤其适合我们这种需要权限控制、限制多端登录的
Web 应用。